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(54) Data access implementation of device driver interface 

(57) A device driver interface (DDI, 1 1 8) for achiev- 
ing portability of device drivers (110) for operating with 
full source level compatibility across multiple instruction 
set architectures and platforms. The device driver inter- j 
face (DDI, 118) makes transparent to the driver (110) 
the actual data access mechanisms of the host comput- 
ers (108, 130) on which the driver (110) is compiled. 
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BACKGROUND OF THE INVENTION 
5 1. FIELD OF THE INVENTION 



10 



The present invention relates to device driver interfaces. More particularly, but without limitation, the present inven- 
tion relates to device driver interfaces that allow device drivers to operate with full source level compatibility across mul- 
tiple Instruction Set Architectures (ISA) and platforms. 

2. PESCRJPTION OF RELATED ART 



In the past, developers of device drivers created separate versions of device drivers that are compatible with spe- 
cific instruction set architectures and with specific platforms of the instruction set architectures. Examples of processors 

is with different instruction set architectures are Intel's x86 (80386, 80486, Pentium), IBM and Motorola's Power PC 
(PPC), and SPARC. SPARC is a trademark of Sun Microsystems, Inc. An example of two specific platforms of an 
instruction set architecture are two computers that have the same processor, but have different memory controllers. 
One of the memory controllers may, for instance, have hardware that can be programmed to do byte swapping and data 
reordering for achieving compatibility between the endian-ness of a processor and that of a device, as is explained 

20 below. 

Examples of device components are a random access memory (RAM) and registers mounted on top of devices 
peripheral to a processor. Such peripheral devices can be add-on boards (e.g., a graphics framebuffer adaptor, a net- 
work interface adaptor, and a small computer system interface (SCSI) host bus adaptor). Devices can be moved from 
one computer to another. Examples of components that appear on these add-on boards are random access memory 
25 (RAM) and registers. These device components have different data representation, such as big or little endian which 
may or may not be different from the computer. (Below, the term "device" refers to devices as well as to device compo- 
nents.) 

Typically, the device driver itself is a set of processor instructions stored in a memory of a host computer for con- 
trolling a device. Sometimes, there are differences between how a host processor and a device communicate and inter- 

30 pret shared data. For example, there may be a difference in endian-ness (byte ordering) between different host 
processors and devices in communicating and interpreting a value stored in a command register on a device. 

There are two major types of endian-ness. One host processor may be little endian, while another processor may 
be big endian. The device itself may be big endian. For example, a processor that is big endian communicates and inter- 
prets a multi-byte word beginning with the most significant byte. Similarly, a processor that is little endian communicates 

35 and interprets a multi-byte word beginning with the least significant byte. Processors with different endian-ness are for 
example the x86 processor family, which is little endian, while the SPARC architecture is big endian. A PPC uses a proc- 
essor which is bi-endian, which means that it has both big and little endian mode settings. Devices exhibit the same 
types of endian-ness. Device A may have a big endian I/O processor and thus communicates and interprets multi-byte 
words using big endian format, while device B may have a little endian I/O processor and thus communicates and inter- 

40 prets multi-byte words using little endian format 

Conventionally, a device driver accounts for the specific differences between a specific host and the device. So, for 
a case of, for instance, a device driver for a little endian device running on a big endian host, the device driver accounts 
for the difference in endian-ness by switching the order of the bytes in the word before passing on the word to the 
device. 

45 However, running the same driver on another host that has the same endian-ness as the device (instead of oppo- 
site) causes miscommunication (or incompatibility) between the host and the device. This incompatibility results from 
the driver switching the order of the bytes in a word. 

Another difference between processors is that processors differ in their data transfer capabilities, specifically in 
their ability to order data. Some processors are capable only of strictly ordering data. Strict order means that the proc- 

so essor can only transmit a stream of data in the same order in which the processor received the data. Some processors 
can only transmit data in the same order as the execution and processing sequence of the instructions. In data reorder- 
ing, a processor can reorder a stream of data. Some processors are capable of data merging. Data merging permits 
combining a single datum into a multi-word data batch and sending the batch at one time, instead of sending one single 
datum after another. Some processors also may have capabilities such as cache loading and cache storing. In cache 

55 loading, the processor can cache data that it fetches and reuse that data until other data is stored in cache in place of 
the original data. In cache storing, the processor can keep data in memory cache and later push it to a device (some- 
times with other data). 

Similar to the situation with endian-ness, a developer tailors a conventional driver to the particular data transfer 
capabilities of the specific host computer. However, a driver written to take advantage of the data transfer capabilities 
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of a specific host cannot be run on another host without those data transfer capabilities. 

A host computer and a device typically are connected by a bus, for example the peripheral component interconnect 
(PCI) local bus. The bus architecture typically includes a bus, as well as a bus bridge, as, for example a PCI host bridge 
and other bus bridges connected to the host bridge, such as PCI to PCI bus bridges and PCI to ISA-bus bridges. To 

5 communicate with a device, a processor can access a device by knowing the device's bus address. In addition, each 
bus address domain may be further divided into separate address spaces. For example, the PCI Local Bus provides for 
three distinct address spaces: Configuration, Memory, and I/O Space. Device registers or memory can appear in any 
of the three PCI address spaces. The method of accessing different bus address spaces can be host computer depend- 
ent. Thus, a driver written to communicate across one bus may be incompatible with another bus. 

10 Another way in which a host can communicate with a device is by sharing a portion of the host memory (DMA-able 
memory) with the device. In this context, DMA-able memory refers to memory used for controlling structures shared by 
a host and a device. DMA-able memory exhibits endian-ness and data ordering characteristics that vary among hosts. 
So, again, a driver written to communicate with a device via a particular host's DMA-able memory may be incompatible 
with DMA-able memory of another host. 

is Therefore, there is a need for a device driver interface that would permit a device driver developer to develop a 
driver independently of the attributes of the hosts on which the device driver might run and of the bus connecting the 
host and the device. This would result in the portability of a driver between various instruction set architectures and plat- 
forms. 

20 SUMMARY OF THE INVENTION 

The invention is defined in claims 1, 9 and 17, respectively. Particular embodiments of the invention are set out in 
the dependent claims. In particular, the invention provides a method and apparatus for achieving portability of device 
drivers, such that device drivers can operate with full source level compatibility across multiple instruction set architec- 
ts tures and platforms. Devices and computer hosts of drivers can have different data access attributes. For example, a 
host can be big endian, while a device controlled by the host can be little endian. An embodiment of this invention pro- 
vides a device driver interface (DDI) environment implementation that supports the data access attributes of the host 
that executes the device driver. The DDI environment uses both the data access attributes of the device and of the host 
to provide data access compatibility between the host and the device. In this fashion, the device driver does not need 
30 information about the host's data access attributes. 

From a process standpoint, a preferred embodiment of the invention comprises the following steps. The method 
allocates memory space in a DDI environment for a handle. The DDI environment selects at least one of at least two 
DDI data access function implementations. The selected implementation accounts for differences between the host and 
device data access attributes. The DDI environment stores information in the handle for accessing the DDI data access 
35 function implementation. The DDI environment passes a handle pointer to the driver for opaque access by the driver to 
the device through the DDI environment, which uses the information in the handle for invoking the DDI data access 
function implementation. As mentioned above, the driver has no information about the host's data access attributes. 

DESCRIPTION OF THE DRAWINGS 

40 

The invention will now be described with reference to the accompanying drawings, wherein: 

Fig. 1 illustrates a general computer block diagram, which shows the portability of a driver. 
Fig. 2 illustrates a flowchart of a set-up procedure of the driver for data access to the device. 
45 Fig. 3 illustrates a sub-system block diagram of the driver and a device driver interface environment. 
Fig. 4 illustrates a flowchart of steps performed by the DDI environment for constructing a handle. 
Fig. 5 illustrates an example of a device driver interface function implementation. 
Fig. 6 illustrates an example of a device driver interface function implementation. 
Fig. 7 illustrates a final outcome of the invention. 

50 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The following description is of the best presently contemplated modes of carrying out the invention. This description 
is made for the purpose of illustrating the general principles of the invention and is not to be taken in a limiting sense. 
55 A preferred embodiment of the invention is illustrated in Fig. 1 . The preferred embodiment of the invention as 
described below is preferably implemented as a portion of an operating system to be released under the name Solaris 
2.5 by Sunsoft, A Sun Microsystems, Inc. Business. "Solaris" is a registered trademark of Sun Microsystems, Inc. It will 
be clear to those skilled in the art that the embodiment described herein may be implemented in various operating sys- 
tems. Furthermore, computer code which is described below is preferably written in the computer language C. C is a 
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high level programming language developed at Bell Labs. But the preferred errtbodiment can be implemented using 
other computer languages as well. 

Fig. 1 illustrates how this embodiment of the invention achieves portability (as illustrated by a double headed arrow 
1 06) of a source code of the driver 1 10. In Fig. 1 , a host computer A 1 08 contains a device driver 1 1 0, which is coupled 
via a processor A 1 1 4 of computer 1 08 to a combination of a common portion 1 1 8 of a device driver interface and some- 
times a DDI host specific implementation 120 (hereinafter, the combination is referred to as DDI). The driver 110 (i.e. 
the source code of driver 1 10 compiled with a compiler (not shown) of host 108) and the DD1 1 18, 120 are stored in 
memory 122 of the host 108. Preferably, the DD1 1 18, 120 are computer instructions, which are a part of the operating 
system of the host 1 08. The driver 1 1 0 communicates with a device 1 26 via a bus architecture 1 28. 

The same driver 1 10 can be compiled to run on another host with a different Instruction Set Architecture (with a 
compiler (not shown)), such as computer B 1 30, which has a processor 1 34 different from processor 1 1 4 ( as discussed 
below, but is otherwise similar to host 108. For simplicity, only two hosts 108, 130 are shown, although, as will become 
clear below, this embodiment makes possible the portability 106 of driver 1 10 among any number of different hosts. In 
host 130. the driver 110 is coupled via processor 134 to a combination of the common portion of the DDI 1 18 with 
another host specific portion DDI implementation 138. As in host 108, in host 130, the driver 110 and the DD1 1 18, 138 
are stored in memory 142 of the host 130. Also, the DD1 1 18, 138 preferably is a part of the operating system of host 
130. The driver 110 communicates with the device 126viaabus architecture 146. 

Device driver 110 preferably is computer code written for controlling device 126, without regard to the particular 
host 1 08 or 1 30 which will execute driver 1 1 0. However, as also described above, there are differences in the ways dif- 
ferent computers process data. For example, different computers have different endian-ness and different data ordering 
attributes. To achieve portability 106 of driver 1 10 between hosts 108 and 130, this embodiment provides DDI host spe- 
cific implementations 120 and 138 for each host 108 and 130. respectively. The driver 1 10 only has to know the partic- 
ular attributes of the device 1 26, such as endian-ness and data ordering. The driver 1 1 0 supplies these device attributes 
to the common portion of the DD1 1 18. The DDI host specific implementation 120 or 138, knows the data processing 
attributes of its particular processor 1 14 or 134 and of the bus architecture 128 or 146, respectively, for which the par- 
ticular host is typically customized. Using this knowledge (as will be explained below), the DDI host specific implemen- 
tations 1 1 8 and 1 38 adjust data passed between the driver 1 1 0 and the device 1 26 by accounting for the differences in 
the data processing attributes and the bus addressing attributes between their respective hosts 108 and 130, respec- 
tively, and the device 126. However, as will be explained below, some hosts 108 or 130 have hardware that obviates the 
need for the DDI host specific portions 120 or 138. 

Fig. 2 illustrates a preferred setup procedure of the driver 1 1 0 for data access to the device 1 26. Fig. 2 is a flowchart 
of that part of the driver 1 10 code that sets up the DDI combination 1 18 and (120 or 138). The DDI combination 1 18 
and (120 or 138) hides the endian-ness from the driver 1 10. In step 210 of Fig. 2A, the driver 110 initializes a device 
access attributes data structure for DDI register mapping. In step 210 of Fig. 2B, the driver 110 initializes a device 
access attributes data structure for DMA-able memory allocation. (An example of an access attributes data structure is 
shown on page 1 of the appendix.) Also in step 210 of Fig. 2 (2A and 2B), the driver 110 stores the attributes of the 
device 126 in the device access attributes data structure. Attributes that are stored are the endian-ness and the data 
ordering attributes of the device 1 26 (see pages 1 -2 of the appendix for examples of values of these attributes). 

In step 21 4 of Fig. 2A, the driver 1 1 0 calls a DDI register address mapping setup function for setting up data access 
with a particular device 1 26. Once the driver 1 1 0 has called this setup function, the driver 1 1 0 has performed all that is 
necessary for establishing compatible communications between the host 1 08, 130 and the device 126 via the bus 128, 
146. (An illustrative list of standardized function names for use by a driver developer is included in the appendix. See, 
for example, the function ddi_regs_map_setup on page 5 of the appendix. The function ddL_regs_map_setup is an 
example of the DDI setup function of step 214.) 

In calling the DDI register address mapping setup function, the driver 110 preferably passes to the DDI register 
address mapping setup function the device attributes pointer and a storage address of the handle (handle pointer 
address). The device attributes pointer contains the address of the device access attributes data structure allocated in 
step 210. The handle pointer address contains the memory location in which the DDI register address mapping setup 
function stores an address of a handle structure, which the DDI register address mapping setup function creates, as 
discussed below. By only requiring the driver 1 1 0 to provide a handle pointer address for the handle structure, the driver 
1 1 0 does not have to know anything at all about the handle structure. In other words, the handle structure is opaque to 
the driver 110. As will become clear below, this opaqueness helps make the driver 110 portable (see arrow 106). 

For data access to control structures within DMA-able memory, in step 218 of Fig. 2B, the driver 110 calls a DDI 
DMA-able memory allocation function for data access via a sharable memory. As described above with respect to step 
214, in making the call, the driver 110 passes to the DDI DMA-able memory allocation function the device access 
attributes pointer and handle pointer address. (For an example of a DDI DMA-able memory allocation function, see 
pages 6-7 of the appendix.) Although, not shown in Fig. 2, the driver 1 10 can be written to contain code illustrated in 
step 214, or step 218, or both. 

Fig. 3 illustrates a preferred communication link between the driver 110 and the DDI environment 310 containing 
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the handle structure 314, all of which is preferably a part of the operating system of the host 108. 130. Fig. 3 further 
illustrates some of the details of the handle structure 314 and how it is used. As discussed above, the driver 110 calls 
a DDI register address mapping setup function. Memory storage space for the handle structure 314 is allocated by the 
DDI register address mapping setup function within the DDI environment 310. Preferably the handle 314 has a common 
5 portion 316. as well as a host specific portion 318 and a bus specific portion 320. The common portion 316 is in the 
common portion of the DD1 1 18 in Fig. 1 . The host specific portion 318 and the bus specific portion 320 is included in 
the DDI host specific implementation 120 of Fig. 1. 

Preferably, the common portion 316 of the handle 314 contains in a memory location 322 a pointer 324, which 
points to the ISA/platform specific portion 318 of the handle 314. Another memory location 326 in the common portion 

10 316 of the handle 314 contains a pointer 328 to the bus specific portion 320 of the handle 314. 

The bus specific portion 320 of the handle 3 1 4 preferably contains data for bus parameters, such as data identifying 
the location of a device 126 on a bus 128 or 146. The ISA/platform specific portion 318 preferably contains in individual 
memory storage spaces 330 addresses 332 of DDI data access function implementations 334. The addresses 332 of 
the DDI data access function implementations 334 are the locations in memory of the DDI environment 310 where the 

15 actual DDI data access function implementations 334 are located. 

As will be explained below, preferably, the driver 1 10 has stored in a memory storage space 336 a handle pointer 
338. This handle pointer 338 points 340 to the handle 314 in the DDI environment 310. As will be explained below in 
more detail, to execute a DDI data access function, such as a read from or a write to the device 126, basically the driver 
110 passes (as indicated by an arrow 344) the handle pointer 338 (as well as other function arguments) to a DDI data 

20 access function call 348. The DDI data access function call 348 indirectly calls (as indicated by an arrow 352) a DDI 
data access function implementation 334. Preferably, the DDI data access function call 348 executes the indirect call 
352 by calling the address 332 of the DDI data access function implementation 334. The DDI data access function call 
348 locates the DDI data access function implementation address 332 via the pointer 324, which points to the ISA/Plat- 
form specific portion 318 of the handle 314. 

25 The selected DDI data access function implementation 334 returns (indicated by arrow 356) a value to the DDI 
function call statement 348. While, for the sake of simplicity, the discussion here is in terms of a single DDI implemen- 
tation function 334, there can be. as shown in Fig. 3, many DDI data access function implementations 334, each of 
which in turn has an address 332. The DDI data access function call statement 348 returns (as indicated by an arrow 
360) the value of the DDI function 334 to the driver 110. 

30 As discussed above, when the driver 110 reads from or writes to the different bus address spaces of the device 
126, it commonly does so via a bus address space on the bus architecture 128 or 146. To obtain the address space 
allocation of the device 1 26. the driver 1 1 0 preferably executes the setup function discussed above, which returns to the 
driver 1 1 0 the address of the device 1 26 on the bus 1 28 or 1 46. As further discussed below, the operation by which the 
DDI environment 310 obtains the device address space location is transparent to the driver 110. This means that the 

35 driver 1 10 can be written by the driver developer without explicitly calling out the different address spaces during data 
accesses. 

To execute a DDI data access function (such as read or write), the driver 110 simply needs to call that DDI data 
access function and pass it the handle pointer 338 and the device address. Examples of functions that read data from 
the device 1 10 are illustrated in the appendix (see, for example, "ddi jgetw" on page 8 of the appendix, which is a func- 

40 tion for reading 16 bit data from a device 126). Once the driver 1 10 has called the DDI data access function, the DDI 
environment 310 takes over and simply supplies a return value, as discussed above in the context of Fig. 2, without the 
driver 1 1 0 having to know any of the details of the DDI environment's 310 operations. Of course, to call DDI data access 
functions, the driver 1 10 had to first execute step 214 and/or step 218 of Fig. 2, as discussed above. DDI data access 
functions other than those for reading data from the device 1 26 may require more input arguments as for example a DDI 

45 data access function for writing data (see page 9 of Appendix). Obviously, writing data to a device 1 26 requires passing 
(in addition to the handle pointer 338 and the device address) the actual data to be written to the device 126. 

Fig. 4 illustrates the preferred steps of constructing the handle 314 of Fig. 3. Rg. 4 is a flowchart of the steps per- 
formed by the DDI environment 310 upon the driver 110 calling the DDI register address mapping setup function in step 
214 in Fig. 2. The DDI environment 310 comprises a common portion 118 (see Rg. 1) and a platform specific portion 

so 120 or 138 in Fig. 1. As discussed further below, the DDI environment 310 performs steps similar to those illustrated in 
Fig. 4 when the driver 1 10 calls the DDI DMA-able memory allocation function of step 21 8 in Rg. 2 for structural control 
data access via sharable memory. Regardless of whether data access to the device 126 is via driver direct accesses 
through the bus 128 or 146 and/or via device accesses to DMA-able memory using direct memory access (DMA), the 
operation of the DDI environment 3 1 0 is transparent to the driver. 

55 In step 41 0, the DDI function setup allocates a memory storage space for the handle structure 314. The allocated 
memory storage space includes memory for the common portion 316, the ISA/platform specific portion 318, and the 
bus specific portion 320. Preferably, however, the ISA/platform specific portion 31 8 is allocated only if the host computer 
1 08 or 1 30 does not have hardware support. In that case, the DDI setup function will use a software function implemen- 
tation, to implement DDI functions 334, as will be explained further below. Similarly, as will be explained further below, 
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preferably the bus specific portion 320 is allocated only if the host cannot directly read/write to the device 126 coupled 
to the bus architecture 128 or 146 through memory mapped address. 

Next, in step 414, the DDI setup function stores in the common portion 316 of the handle 314 input arguments that 
were passed to it in step 21 4 of Fig. 2. As mentioned above, input arguments that are passed from the driver 1 1 0 to the 

5 DD1 1 18 include the device access attributes pointer and the handle pointer address 336. The device access attributes 
pointer points to the memory structure in which the driver 1 1 0 has stored the device attributes, such as the device's 1 26 
endian-ness and data ordering characteristics. In step 214 of Fig. 2, the driver 1 10 also passed information to the DDI 
register address mapping setup function about an index number to an address space set representing certain device 
registers. In addition, in step 214, the driver passed an offset and a length relative to that address space set of the 

10 device registers. 

From these input arguments, the DDI register address mapping setup function, in step 422, identifies the bus 
address space location of the registers on the device 126. As mentioned above, the method of setting up bus address 
space mappings into host address domain is host computer 108 or 130 dependent. As explained below, the DDI envi- 
ronment 310 makes this host dependence transparent to the driver 1 10. For example, in the case of PCI devices (i.e.. 

is devices connected to the PCI Local Bus) the returned address (that is the address returned by the DDI function setup 
to the driver 1 10) can be either an address within the PCI Memory, I/O, or Configuration Space. The driver can use this 
returned device bus address as a base to derive effective addresses for other device 126 registers in the same address 
space. The driver 1 10, preferably accomplishes this address derivation by either adding a constant as an offset to the 
device bus address base or by casting the bus space address base as a pointer to a C language data structure repre- 

20 senting the device 126 registers. 

Next, the DDI register address mapping setup function identifies the device data access attributes of the device 
1 26. In step 426, the DDI function register address mapping setup identifies the endian-ness requirements of the device 
126. As mentioned above, in step 210 in Fig. 2, the driver 110 stores the endian-ness attribute of the device 126 in the 
device data access attributes data structure. For example, if a flag data "NEVER SWAP" is set, a byte swap will not be 

25 used. If the endian-ness of the device specification does not match the endian-ness of the host, a byte swap will be 
used under all data accesses, as explained below. 

Next, the DDI register address mapping setup function preferably executes a step 430, unless the host computer 
108 or 130 can only access the device 126 with strict data ordering. In this case, strict data ordering is used under all 
data accesses. The DDI setup function retrieves the device's 126 data ordering specification from the device access 

30 attributes structure. The DDI function then selects a data ordering method based on the host's 108 or 130 capabilities. 
For example, if the driver 126 specifies merging, but the host 108 or 130 can only perform data reordering, then data 
reordering, which is less flexible than merging, will be used under all data accesses. 

Since each DDI implementation 120, 138 is written specifically for the particular host 108, 130 respectively, there 
is a split in the steps that are taken next by the DDI setup function. The split (B1 , B2) occurs because some Instruction 

35 Set Architectures and some platforms of Instruction Set Architectures have I/O hardware support (B1) and other 
Instruction Set Architectures and platforms (B2) do not have. Those Instruction Set Architectures and platforms have 
I/O hardware support which permits the DDI register address mapping function setup in step 434 to program the hard- 
ware to account for the device attributes, such as endian-ness, data ordering and bus address space mapping require- 
ments, in the B1 branch, preferably, the DDI register address mapping setup function of the particular DDI 

40 implementation 120 or 138 does not allocate storage space for the ISA/Platform specific portion 318 and bus specific 
portion 320 of the handle structure 314. The reason for this will become clear below. 

In step 442 of the B1 branch, the DDI setup function does the bus address mapping of the device 126. In some 
cases, the bus architecture 128, 1 46 includes hardware that allows the DDI setup function to program the bus hardware, 
which then automatically executes the bus address mapping of step 442. Without such bus address mapping hardware 

45 capability, the DDI implementation 120 or 138 in step 442, preferably involves selecting suites of software functions, as 
explained below in the context of the B2 branch of the flowchart of Fig. 4. 

In step 442 of the B1 branch, the DDI register address mapping setup function does the bus address mapping of 
the device 126. In step 444 of the B1 branch, the DDI setup function sets the handle pointer 338 to point to the newly 
allocated handle 314. A separate handle 314 is allocated for each device 126 address mapping, when the driver 110 

so calls the DD I register address mapping setup function. 

In step 446, the DDI setup function returns control to the driver 1 10. In the process of doing so, the particular DDI 
implementation 1 20 or 1 38 passes to the driver 1 1 0 the device bus address as obtained in step 442 and stores the han- 
dle pointer 338 in the memory storage 336 of the driver 1 10. 

In the B2 branch of the flowchart in Fig. 4, the DDI register address mapping setup function executes step 438. In 

55 the B2 branch, the particular DDI implementation 120 or 138 does not have the hardware support in the host computer 
108 or 130. In step 438, the DDI setup function identifies a suite of DDI data access function implementations 334 (see 
Fig. 3) for accessing the device 126. As explained below, the DDI data access function implementations 334 use soft- 
ware methods to handle the attribute differences of the host processor 1 14 or 134 and the device 126. As discussed 
above, the DDI setup function stores the addresses 332 of the DDI data access function implementations 334 in the 
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ISA/piatform specific portion 318 of the handle 314 in memory storage 330. 

An example of a DDI data access function implementation 334 for software byte swapping is illustrated in Fig. 5. In 
Fig. 5, the driver 110, running on a little endian processor 114, sends a four-byte word 514 to a big endian device 126. 
The DDI data access function implementation 522 (334 in Fig. 3) swaps the order of the bytes of the word 514 and 
5 transforms the word 514 into a big endian device word 518. Fig. 6 shows another example of another DDI function 
implementation 610 (334 in Fig. 3). In Fig. 6, the driver runs on a host processor 134 that is big endian. Here the driver 
1 10 is sending a four-byte word 514 to a device 126, which is also big endian. In Fig. 6. the DDI data access function 
implementation 610 does nothing or is a no-swap function, which preserves the order of the bytes in the word 614 as it 
existed in the word 514. 

10 Another example of DDI data access function implementations 334 are functions that use capabilities of some 
processors to reorder data, to merge data, to do cache loading, and/or to do cache storing. For example, the driver 110 
may advise the DDI environment 310 to use certain data ordering attributes. As discussed above, the driver 110 gives 
permission to use certain data ordering attributes by setting appropriate flags in the device access attributes structure 
(see page 1 of the appendix for examples of such flags). As shown in the appendix, giving permission to do one type 

is of data ordering may imply giving permission to do other types of data ordering. 

A library of different DDI data access function implementations 334 are stored in the operating system of the host 
108, 130. preferably in the DDI environment 310. In step 438 of Fig. 4, the DDI environment preferably executes 
if/then/else statements, to decide which addresses 332 of which DDI data access function implementations 334 to store 
in the ISA/platform specific portion 318 of the handle 314. To illustrate, a computer instruction in the DDI register 

20 address mapping setup function of the DDI implementation 120 or 138 for a little endian host processor 1 14 or 134 may 
read as follows: if the specified device access attribute is big endian, then store in the memory storage 330 the 
addresses 332 of the DDI data access function implementations 334 that do byte swapping for reading from and writing 
to the device 126. Then, when the driver 110 invokes a DDI data access function that, for example, sends a four-byte 
word to the device 126, the DDI data access function call 348 is executed indirectly 352 by calling the DDI data access 

25 function implementation 522 of Fig. 5 (334 in Fig. 3). In this embodiment, had the specified device access attribute been 
little endian, then the DDI implementation 120 or 138 would have stored in the memory storage 330 the addresses 332 
of the DDI data access function implementations 334 that do not perform byte swapping for reading from and writing to 
the device 126. 

Similar to the handling of the endian-ness issue, in step 438, the DDI setup function of the DDI implementation 1 20 
30 or 138 also executes if/then/else computer instructions for selecting from the library of DDI data access function imple- 
mentations 334 the appropriate addresses 332 for data ordering and different bus address space accesses. 

Returning to Fig. 4, in step 442, of the B2 branch, since the data access functions are performed using a software 
method, the DDI register address mapping setup function preferably stores certain bus specific information in the bus 
specific portion 320 of the data access handle 314. When accessing the PCI Local Bus Configuration Space, an exam- 
35 pie of bus specific information is the device's 1 26 location in terms of bus number, device number, and function number. 
This information can be used by the selected DDI data access function implementation 334. Returning to the B2 branch 
of Fig. 4, following step 442, the DDI setup function executes steps 444 and 446 in a manner similar to that of branch 
B1 of Fig. 4. 

This embodiment, as illustrated in Fig. 4, is preferably modified when the device 126 and the host computer 108 or 

40 130 communicate using the direct memory access (DMA) method, as discussed above. Basically, the DDI DMA-able 
allocation function illustrated in Fig. 4, executes all of the steps shown in Fig. 4, except steps 422 and 442. Step 422 is 
not used, because in the direct memory access method, the device and the host communicate by accessing memory 
internal to the host 108. 130, thereby obviating the need for using the bus 128. 146. Similar reasoning leads to omitting 
step 442, which involves doing bus address mapping. 

45 Fig.'s 7A and 7B illustrate and summarize how the driver 1 10 executes a DDI data access function. Fig.'s 7A and 
7B are similar, except that in Fig. 7A hardware (H/W) support is available for performing I/O, whereas in Fig. 7B there 
is no hardware (see steps 714 and 718, respectively, as discussed below). However, as discussed above, the presence 
or absence of this hardware is transparent to the driver 1 10. In steps 710 of Fig.'s 7A and 7B. the driver 110 calls a DDI 
data access function such as one for writing data to a device memory or register of a device 126 or even to data control 

so structures within an allocated DMA-able address (see, for example, page 8 of the appendix). In step 71 0, the driver 1 1 0 
passes 344 (as discussed in the context of Fig. 3) the device bus address (or a DMA-able memory address) and the 
handle pointer 340 to the DDI data access function call statement 348 in the DDI environment 310. 

In step 714 of Fig. 7A, the DDI environment 310 (see Fig. 3) uses the I/O hardware, which it has programmed. 
Therefore, in step 714, the data access DDI function is executed by a direct read/write to the device bus address. Next, 

55 in step 722, the DDI data access function returns control to the driver 110 (along with a value of the DDI function called 
by the driver 110, if appropriate). For the case of the driver 110 sending a word to the device 126, a result of the function 
called by the driver 1 10 is that the word has been written from the driver 1 10 to the device 126 at the specified device 
bus address, accounting for the endian-ness and data ordering attributes differences between the driver 110 and the 
device 126. 
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In step 718 of Fig. 7B, the DDI environment 310 has no I/O hardware. Therefore, it uses a software implementation 
method. Here, the DDI environment 310 executes the function requested by the driver 1 10 by indirectly calling 352 the 
appropriate DDI data access function implementation 334 for, for example, writing a word to the device 126 to the 
appropriate device bus address. Thereafter, in step 722, the DDI environment 310 returns control to the driver 110. 
5 Several preferred embodiments of the present invention have been described. Nevertheless, it will be understood 
that various modifications may be made without departing from the spirit and scope of the invention. For example, the 
DDI environment 310 could account for host 108, 130 attributes, other than those mentioned above. Thus, the present 
invention is not limited to the preferred embodiments described herein, but may be altered in a variety of ways, which 
will be apparent to persons skilled in the art. 
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SAME 

ddi.icvice.jcc.ior - dm access uinbuies structure 

SYNOPSIS 

^include <srSrddiJi> 
-include csyssu oddi.h> 



10 



IMERFaCE level 

Solam DDI jpecinc (Solaris DDD. 

DESCRIPTION 

The ddi_device.act.attr structure describes (he dia access characteristics ad rca^nremenis af Ok dev- 
ice. 

STRUCTURE MEMBERS 

ushort.t devscc.aw. version : 
uchar.t devacc.atn-.endian.flags; 
ochJT.t devacc.acir.dataocder: 

The devacc.attr.versioe mrmbrr idea-dies (he version emmber of this stracmre. The current version 
20 aitnhff is DOl.OEVlCE.ATTR.Vfl. 

The devacc.ittr.eadiia.&afj mrffiher describes the endien caaracterisocs of die device. Specify one 
of the foUcmnng values. 

DOI_NEVZKSWAf_ACC 

dua access with oo byv rwapping. 

DDl_STRUCTURE_DE_ACC 

structural data exna is big eodiao farm ay 

ODl.STKUCTURE.LE.ACC 

scnjcural data access in litxie eodiao fom^a^ 



35 



40 



25 



30 ODt.STRUCTURZ_fiE.ACC and DOI_STRUCTURX.LE.aCC describes the eadian charaewshes of the 

device as bit; eodiao or little eodiaa. reapecsvdy. Eves (hough moat of toe devxxa will have die same 
endian cha ra asaso cs ea their buses, dm an eneapiei of device* vita I/O aa proceaacr that has oppo- 
um esdian ca g > .iniioci of cat base*. When DDI_STRUCTUR£.BE_aCC or 
00C_STRUCTUR£_L£_ACC is set by* rweppmg vill ttunmiririlty be performed by the sysaan if (be 
host machine aad da device data formats have c?potiae eodiaa characaeroacs. The impfcmentarion may 
take advantage of hardware platform byte swapping capabtHaes. 

When DD(_xeverswaP_aCC is specified, by* swapping win not be invoked in the data trn i func- 
dooa. 



The d*vacc_aa*_dataorder member describes order in vtuch (ha CPU will r eference data. Specify one 
of (he following vetoes. 

ddi_strictordex_acc 

The data if frrnn n must be issued- by a CPU in program order. Stria ordering is 
the default behavior. 

DDC.UNORDERXD.OK.ACC 

45 The CPU may re-order (he dam refatneca, This iaduoes all kinds of re-ordering. 

Cut. a load followed by a store may be replaced by a store foUowed by a load). 

DDl.MERGING.OK-ACC 

The CPU may merge individual acres to consecutive '^'""i For example, the 
CPU may urn two consecutive byte stores into one halfword store. It may also 
so batch individual loads. For example, me CPU may turn two coosecudve byte loads 

inm one halfword load. DDLMERGINC_OK_ACC also implies re-ardenag. 

00I.LOAJ)CACHINC.OK.ACC 
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fbe c?U any c^*" tlx <Uu a fecbc* and reuse u una! anomer store occurs. The 
jcfam behavior is to fesch new data oa every .cad 
OOI.LOaDCaCHING.OK.aCC also iffiplks me/pag ud re-ordering 

DOI .5T0RECaCKINC.0K.<CC 

fie CPU may keep (be dia in (be cache and push ix to me device perhaps *uh 
r0 xher <uu) at a liter an*. The default behavior is to push the dau nghi away. 

DOI.STORECaCKINCJDK.aCC also implies load caching , merging, and re- 
ordering. 

These values are advisory, not aundajcry. Far example, dau can be ordered without being merged or 
cached even though a driver requests unordered, merged and cached (ogeiner. 

15 

EXAMP1XS 

The following examples Ulustnxe me use of device register address mapping setup functions and dif- 
ferent data access funcaons. 
fyimpta 1 

This exiffipke oemcnsniea me use of me OjdLdence.acc.attr smaanre in ddi.rep.oiap.setup<9F). 
Ix also snows me use of ddi_gerw<9F) and ddijMtwtfF) funcaons in acretting me register conients. 

dev_ta/o_t *dip: 
dint j niambcr; 
asaortj •dev.*ddr; 
orTset.t offset: 
25 offset.t ten: 

usnort.t drr^commind: 
ddi_device_acc_artr_t dev.attr: 
ddLacc_bandte_t handle: 

30 

• 

" setup Use device artnoote sCnactart for fittk endiaa, 
* strict ordering and I6~bd word access. 

35 drr„ittrAcTKz_uxr_**F*am » DOLDEVlCZ^ATTTt.Vf; 

dev_attru*eracc_a»_en«M_aa*s * DOLSTRUCTURE.LE.ACC; 
dev_attroievacc_attrjia£t*rder = DCM.STRiCTORDER^ACC; 



20 



40 



• set up dae device registers address mapping 

•/ 

ddi.rets.a»ap.setnp<dip, ru umber, (caddr.t •)£der_addr, offset tea, 
eVder.tdr. & handle); 

• read a IMxt word command register front the device*/ 
45 dev .command * ddijetwihandle, det jaddr); 

dev.command I = DEV. GNTR .ENABLE; 

• store a new vaJoe back to the device command register*/ 
ddi jxitw(nandJe, dev_addr, dev.command); 

SO Exampte 2 

The foil owing eaampte illustrates the saep* used to access a device vim d tfE c x eai apertures. We assume 
mat several apertures are grouped under one singk "leg" entry. For example, (be sampie device has tour 
different apertures each 32K m sue. The. a p er t ur e s represent YUV Utrie-endian. YUV bi£-eadian. RGB 
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15 



20 



40 



50 



UtuVendiia. ud RGB big-endian. This samps device use* eaery I of cbe 'ret* property Uk for uus 
purpose. Toe sia of (bo address space is i28L wim each 32X finae u i separas aperture, la he regis- 
-XX mapping setup function, the simple driver uses the offut ad fcfl pirimears to speofy one of the 



apertures. 

ulonfcj 'dev.addn 
ddi.de* ice.acc.artr J dev.attr; 
ddi.accjiandk.t handle: 
uchar.t bu/1256]; 



• setup the device attribute structure for never swap, 

- unordered and 32-bit word access, 

•/ 

d«T trtr.dev*cc_aCtr.ver9oa * DOLDEYICE.ATTH.Vt; 
dev attr-aeracc ittr.endian.ttags ■ DDLNEYERSWAP.ACC; 
devlattr^acclattr.dataorder * DDLUNORDERED.OK.ACC: 

• 

• map in the RGB btf-endian aperture 

• while nanninf in a be* endian machine 
25 • . oflaet 96K and lea 32K 

•/ 

ddLrefS.map.setop<dip, L, (caddrj •)*dev_addr, 96*1(04, 32*1024, 
&dev_attr, & handle); 

■ 

30 ■ Write to the screes boiler 

- first IK bytes words, each size 4 bytes 
•/ 

ddi.rep jHrtKiaadk, tmt dev.addr, 256, DOLDEV^AUTOtNCR); 
Exuapte 3 

35 The following example ilhmates dm use of (be functions (hat explicitly call out the dau word size to 

override (fan dau an m (fan device ttmbuse souemm 

struct device J>* ( 

f coeanumd register •/ 
/• states register V 
oioot d.data: /• data reenter •/ 



J 'dcr.Wkp? 



devjin/bj *dip; 
caddrj de? .addr; 
ddi.device.acc.attr.t drr.attr; 
45 ddi.acc JiandkJ handle; 

ucfaar J boil 256]; 



* setup the device attribute structure for never swap, 
■ strict ordering nod 32-Nt word access. 
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d«v_attr^evacc_amv«k» * DDl_DEVICE_ATTR_Vt: 
d«v_attr.d«vacc_attr_«diafl_aats * DDt.NEVERSWAP.ACC; 
dev_attr.devacc_attr_dataocd«T5 DOLSTRICTORDER.ACC; 



ddLre€5.cnap.$«tup(dip, I, (caddrj •)Ader - blkp f 0, 0, 
dtdev.attr, Atuodk); 

/• write command to the IWnt coco m tad register V 

ddi _putwtfuAdk, Ader^Wkp- xj.com ataad, START.XFER); 

/• Read the 16-bit stadu reftttcr V 

sums a ddl^genKhaadk, &derJ>lkj>->d_*atBS); 

if (statu * OAT ALREADY) 

/• Read IK bytes off me 32-btt data raster •/ 
ddLrtpjedfraadle, twf, &d*v _b&p->d_data, 
256, DOLOEV.NO.AUTOINCR)? 



ddi_j«w(9F). ddLpatwOT). ddLrecs_map_*tsp(9F), 

Writing Dtvict Driven 
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SEE aX-SO 
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NAME 

ddi.regs.aup.secup - sec up a mapping for a register address space 

SYNOPSIS 

*inciudc <aysddiJi> 
10 ^include <svssuaddiJi> 

iat ddi.regs_map_seaip(d«v_info.t 'dip, uiat.t number, caddr.t •otfern, 
offset.! oj^er, orTset.t ton. ddi.de vKe.acc.atsx.t •occawy, 
ddi„acc_bAHdk.t •handlep)-, 

availability 

« PO UocaI 8m. SBus. ISA. E5A. MCA 

ARGUMENTS 

iip Pointer to the device's der.iafo st r uanre . 

number Index number to tlx register address space set 

a44rp Poinaer to the nipping address base. 

offset Offset into 6e register address specs. 

i>A Length to be (nipped. 

accanrp Poinaer to a device access attribute structure of this device (see 

ddi.device.»cc.sitr(9S)). 

handlep Poinaer to a dsu eccess handle. 

INTERFACE LEVEL 

Solaris DDI specific (Solaris ODD. 

DESCRIPTION 

30 d<ti_rep_tnap_setnpO nape in the register set given by number. The register number 

which register set is supped d more dun one exists. 

offset s peci fi es the starting location within the register space and len indicates dm toe of (be area to be 
supped. If len ts non-sera it overrides the fengm given in the register set onscripdon. If boa len end 
ojfstf are 0. the entire specs is m *tT*^ Tne beam of am mapped regisaer spece is re un ne d in addrp. 

The device accent actribnacs cm specified a the location ponued by the accaarp ergumcnt (see 
ddi.device.ecc.im<9S) for details). 



20 



25 



The data access bandit is returned in htmdlep. handle p ts optoot - driven should not taempt to inter* 
pre* ita value. The handle is used by the system a encode mfrrmtnna for subsequent date access face* 
dot ceils *> maintain t consistent view between the boat and the device. 

RETURN VALUES 



OOLSUCCZ38 Successfully set op tbe mapping for data access. 

DDI_FAILUV Invalid register number number, offset offxi. or length ten. 

45 D01JIECS>CC.C0NFUCT 

Cannot enable the register mapping doe to f^fii rr9r *Kn with other enabled 
mappings. 

CONTEXT 

50 ddi.regs.tnap.setnpO must be called from user or kernel context. 

SEE ALSO 

dtii.rep.tnap Jr*e<9F). ddi.device.acc.sttr(9S) 
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SAMZ 

ddi,dnu,mcm.altoc - ailocat; memory for DMA transfer 

SYNOPSIS 

tfiadude <3rs/ddLh> 
#indude <3ys/suaddiJi> 

int ddi.dma_ajem_alJoc{ddi.dma_lufldle.t handU, uintj Ungth, 
ddi_device_acc_attrj 9 occaarp t aloeg_t jfarr, 
int { •HS2j^?i(caddr.t), caddr.t org, caddrj •kaddrp, 
uint.t Teaijength, ddi_acc_handle_t 9 handUp)\ 

ARGUMENTS 

Tlx DMA handle rxrviccsly allocated by i call to <WLdms_tUoc_handk<9F). 
k/ijtfr The length in byes of the desired i toarion 

ac corny Pctnrr to a device access scribe* structure of this device (see 

otf_devk*.scc.attr(9S)). 

Data transfer mode flags. Possible vsiues are: 

DD(_DMA .STREAMING Sequential, tmirfimrrirmal. block-sized, and block- 

DDLD MA .CONSISTENT Nonsequential transfers of small objects. 

wQitfp The address of a function to call back laser if resources are act available now. The 

special function addresses DDU>MAJSLZEF and DDI _dma_DONTWatt are taken to 
mean, respectively, wait until resources are available or. do not via and do not 
srhrrtnle a callback 

org Argument to be passed to the callback function, if such a function is «r~n*H 

taddrp On successfu l return. *kaddrp points to the yw^iH memory. 

•reat_Ungth The amount or memory, in bytes, allocated Alignment and padding requiremeots miy 

require ddi_dina_mem_aJloc() to allocate more memory than requested in Ungth. 
handle p Pointer to a data tti handle 

INTERFACE LEVEL 

Solaris DDI specific (Solaris DDT). 

DESCRIPTION 

d<U_dma_mem_aJlocO allocates memory for DMA transfers to or from a device. The ailocarion will 
obey che a ligrrmrrtr . padding constraints and device grmnlsriry as specified by the DMA artributes (see 
ddi.dntn.aitr(9S)) passed to ddi_dma_tlloc_ks*dk<9F) and the more restrrtive auribuats imposed by 
the system. 

flags should be set to DDU>MA_STR£AMING if the devise is doing sequential, unidirectional block* 
sized, and block-aligned transren to or from memory. The alignment and padding constraints specified 
by the minxfer and burstmes fields in the DMA attribute structure, ddLdma.attr<9S) (see 
ddi.dma_ailoc.handk(9F)) will be used to allocate the most effective hardware support for large 
transfers. For example, if an I/O transfer can be sped up by using an VO cach e, wtuch has 
transfer of one cache line. ddijlnujnea.allocO will align the memory at a cache line boundar y and it 
will round up m realjength to a mulnpk of the cache line size 

flags should be set to DD(J)MA.CONSISTENT if the devke t r r r » f i memory randomly, or if synchron- 
izarion steps using ddi.drju.STnc<9F) need to be as efficient as possible. VO parameter blocks used for 
comnrunicari on between a device and a driver should be allocated using DDLDMA.CONSETENT. 
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The device access imitates tie specified in the location pouutd by the decamp argument (see 
ddijievke_acc_attr(9m 

The dm access is returned in handlep. handUp is opaque - driven may act attempt to interpret 

its v&hie. To access the dau content the driver must invoice ddi_getb<9F) or ddi_getb<9F) (depending 
an the dau transfer direction) with the data ac ce s s handle 

DMA resources must be Mfihlitfyd before performing a DMA transfer by passing kaddrp tod 
•real ^length as returned from ddLdtn^neaa.aikxO and the flag DDI J) MA .STREAMING or 
DDl_DMA_ CONSISTENT to ddi.dma^ada>_btn<Lhandle(9F). In addibon, to ensure the consistency 
of a memory object shared between the CPU and (tie device after a DMA transfer, explicit synchroniza- 
don steps using <kti_dma_jyuc(9F) or ddLdma.oabiad.haa)d]e<9F) are required. 

RETURN VALUES 

ddi.dma.metn^aOocO returns: 

DDI .SUCCESS Memory successful^ allocated. 

DDI.PATJLURJS Memory iUccation failed. 

CONTEXT 

ddi_dma_mem_afloc< ) can be called Cram user or inaezrupt cmtrrr, except when waifp is set to 
DDI.DMA.SLEEF. in which case it can be called from user, context only. 

SEE ALSO 

ddi.dma_addr.btnd_handJe(9F). ddi.dma.alkx_liajkdle<9F). ddi dma a □ bind handle<9F) 
ddLdma.mem Jree<9F). ddi_dtna,i7nc(9F), ddi_gettK9F). ddi jwtb(9F) 

Writing Device Drivers 
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NAME 



ddLfecb. ddi jerw. ddi_gttL ddijetll - read data from (be (nipped memory address, device register or 
allocated DMA memory address 

SYNOPSIS 

fadude <ay^ddUi> 



udur.t ddi^gedKddi^acc.tuiidle.t Aa/idie, ocaarj •rfrvarf*); 

ostort.t <Jnl jetw<<kiLaccJiandk_t Aarktfe, assort j •irvddttr); 

alocct ddlj«d(<klJ.tcc.JuiidkJ toufle, about •drvaidr); 

75 ansoned k»| too* ddjetiXddLacc.handk.t toktit, 

aasifMd too* baf •devjaddr); 

WTEWACZ LEVEL 

Solaris DDI sped*: (Solaris DDD. 

20 ARGUMENTS 

Aa/vfl* The dau aacess handle renamed from seam calls, such at 4o1_re&.au0_jetap(9F). 

drtjddr Base device address. 

DESCRIPTION 

The ddLgcttt). ddi_jetw<), ddijenX). and ddi^liK) foocdocs read3bus,l6bas,32biamd64 
25 bin of data, respectively, from the device address, da jddr. 

Each tolividnal datum will rmnmirrilfy be translated id maintain a ^^«^* view between me boat 
tad me device based oo me encoded information in me dau access handle. The translation may involve 
byte-swapping if (be host and die device have irrarnpirihlc endian characserisdes. 

3o rcturn values 

These fuocnons return (be value read Cram (he mapped address. 
CONTEXT 

These functions can be called from user, kernel, or mnt*** 
SEE ALSO 

35 ddijxitN 0 ! 1 ). ddi_rep^etb(9F). ddi.repjwtbX^. ddi.r^s.map.setnp(9F). 

<tti_r^_aiap_rr«e<9F) 



w 
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5 NAME 

ddijax©. ddi jjcrw. ddi jud. ddijjudi - write data to (be mapped memory address, device register or 
til oc tied DMA memory address 

SYNOPSIS 

tfindude <3y*/ddUi> 
yo tiodude <3rs/«addi.h> 

void ddi_putb(ddi_acc_tundk_t handle, udur.t % dtn m addr % odurj value); 

roid ddi_patw<ddi_ftGCjUJidle_t handle, assort _t *dnjsddr t tsnoct.t vaA*); 

void ddi jwd(ddj.«x.hifldlej A^, a*o«t_t •deyjoddr, tfaact veiu*); 

75 ^ ddi jmtU(ddL»a_fc4fldkJ Aamik, eastfaed toe* loo* •drvaddr, 

napped toag loaf wto*); 

INTERFACE LEVEL 

Solaris DDI specific (Solaris DDD. 

20 ARGUMENTS 

The data access hmrfk reamed from seap calls, sodi as 4di_r%ta.oupjKtap(9F). 
value "The dau to be written to die device. 

devjxidr Base device address. 

DESCRIPTION 

25 These rourioes gencraae a wriae of various sizes to the mapped memory or device register. The 

ddijwtbO. ddUwtw<). ddijwt*), sad ddLpotflQ aocdooi wriae 8 bits, 16 bits, 32 bo* and 64 bio 
of data, respectrveiy, to the device address, devjzddr. 

Each individual datum will antomaticaUy be translated to maintsia a copsisteni vvv between (be host 
tod the device based on me mcodcd mfoemaooa in me dau access h«*<u The tr ansuri on may involve 
30 byae-rwappiag if the boat and the device have mcompaabk endiaa charaoerisoci. 

CONTEXT 

These cuncoons can be called from user, kernel, or i nto nipt ™*V» t« 
SEE AJLSO 

35 ddi jetb(9F). ddi.rep.aup.free<5f), ddi.refs.aa«p,set«p(9F). ddi rep_tetb<9F>. 

ddi_r*p_p«rt»<9F). ddi_d<vice_acc_attr(9S) 
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APPENDIX 



NAME 

ddi.rep^getb. ddi.repjetw. ddLrepjeti. ddi_rep_getU - read dm from (be mapped memory address, 
device register or allocated DMA memory address 

SYNOPSIS 

#indud« <3ys/ddi.h> 
4uicJud< <5ys/sunddiJi> 

void ddLrep_xetb(ddi_acc_lundl«J Ao/uu>, udur.t 'hcstjddr, ucharj •oVvjsddr, 

Mini J, repcouni, uloa|_t/d£j); 
void ddi_rep_getw<ddLattJiMdkJ Jiandk, ttshort.t *ho*jsddr t labortj 9 d*vjiddr t 

uint.t rcpcowu* uloagj Jlajr); 
void ddLrtpjetKddLscc.anndk.t Aandl«, aioas*J •hoxjadb, aloo*_t •dcvjiddr, 

tdatjt repcowit, akag_t jtaf s); 
void ddi.rcp^ctlKddi.ftoc.luadk.t ensfsed kwg loaf •host_addr, 

unsigned loaf kxtf 9 dc*j)ddr t uurt.t repcowu, ato*gJL fas); 

20 ENTER/ ACE LEVEL 

SoUris DDI specific (Solaris ODD. 

ARGUMENTS 

haAdU The dm access hindk returned from semp calls, such as ddLrtp.mnp.setnptfr"). 

hostjddr Base hoc address. 

dnjddr Base device address. 

rtpcouns Number of data, accesses to perform. 

Device address lags: 

DOLOEV.AUTOWOt 

Amnrnarirauy uxremcnt the device address, dcvjiddr. during dan 



70 



75 



25 



30 



DDLOEV_NO_AUTOINCa 

Do act advance the device address, dnjiddr. during dan accesses. 

35 DESCRIPTION 

These routines generate multiple reads from the mapped memory or device register, rtpcount data is 
copied from (he device address, dctjddr. to me host address, kostjddr. For each input damm, (he 
ddi.rep^etb(X do1_rep.jetw<), ddi.rep.cetK). sod d<fi_rep_getii<) funcaons read 3 bio. 16 bux 32 
bits and 64 bits of data, respectively . from me device address, dnjddr. drtjddr and hostjddr must 

40 be aligned to the d antra boundary d escri b e d by the function. 

Each individual datum will atnomiticalfv be translated to mtrrtfain a mnrittrm view between the host 
and the de v i ce besed on the fn c ylH tm^onnadon, m me dau access han dle The translation may involve 
by tt'Sw apphsg if the host and the device have tnconspenhto characteristics. 

When the flags argument ia set to DDIJ)EV^\UTOINOL these functions (rest the device address. 
45 devjddr, as a memory buffer location on the device and mrrrmrnf its address on the next input datum. 

However, when (be /top argument is to DDLOEVjtOjtUTOtNCH the same device address will be 
used for every datum access. For example, this flag may be useful when reading from a dau register. 

RETURN VALUES 

These functions return the value read from the mapped address. 

so 

CONTEXT 

These functions can be called from user, kernel or interrupt cmtrrt 
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ddi_t«b<9F). ddi j>utb(9F). ddi.rtpj>«tb(9F) < ddLr«p_aup_imp<9F). ddi_repjaap_fpet<9F) 
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NAME 

ddLrcpJxub, ddLrep_purw. ddi.repjjutl. ddi_rep.pudl - write diu to (he mapped memory address, 
device register or tlkxtieri DMA memory address 

SYNOPSIS 

aHudude oys/ddi Js> 
findude <3fi/saaddUi> 

void ddi_repjHitb<ddLacc.hand]«_t te/tdk, udurj •hastjsddr, udxir.t •dajiddr, 
uint J repcowtt, uho%J flags); 

void ddLrepjHrtw<ddi.aa:.lundle_t handU, ushort_t % hostjddr % asbort.t *deyjxldr % 
uint.t repcouAS, vlomu flags); 

void ddLrtpjwtKddi.»cc.htfldlej Annafc, aJoa*_t •hostjsddr, sJoogJ •dojsddr, 
uint.t rcpcouAi, vkso^jL flags); 

void ddi.rep^otU(ddi M aoc.haodl«.t fcz/idif, anstgsed tag loaf •fcxsfjaddr, 
unsigned k5ag tag •devjaddr, uiat.t rtpcouns, uioo^J flags); 

20 rVTERyACE LEVEL 

Solaris DDI specific (Solaris ODD. 

ARGUMENTS 

Aoidfe The data access handle reenrne d from setup calls, such as ddLrep_map_setup(9F). 

hozt_addr Base host address. 

dctjsddr Base device address. 

repcouAi Number of dau acrrwi to p e rfo rm. 

flags Device address flags: 

DDCDeVjUmXNOt 

Asfioauocalry iocremeat the device address, devjsddr. during dau 



10 



15 



25 



30 



DDLOEV.NOj^UTOINCR 

Do not advance the device address, drfjsddr. during dau ; 
35 DESCRIPTION 

These routines generate muitzpk writes lo the mapped memory or device ctpsaa. repcouns dau is 
copied from the host address, test odrfr. to the device address. 6a addr. For each input datum, the 
ddi.repjwtbO, ddLrep jHrtw< X ddLrep ). sod ddLrepjairik) rmrrirm wriss * bus. 16 bio. 
32 bits and 64 bits of data, respecuvdy. to the device address, dev addr. der addr and hest addr most 
be aligned to the datum boundary deacribed by the roncne* 

Each indmdnal damn will tmnmariralty be translated id m****™ a vew between the host 

and the device baaed on (he encoded mfonnadoa in (he dau access handle. The ransiadou may involve 
byv-fwmppag if me boat and the device have i nrorc p ti i'b k e nrii a e ch ars s a er isu q. 

When the flags argument is set to DW_DEV_AUTOCNCR. these fattens (real the device address. 
dotjsddr, as a memory buffer location on (he device and mcrement its address on (he next input datum. 
However, when (he jfoa? argument is to DW_DEV_W - AUTOC<CR, (he same device address wiU be 
used for every damm access. For example, this flag may be useful when writing to a dau regis aw. 

CONTEXT 

These functions can be Called from user, kernel, or interrupt co ntext 
50 SEE ALSO 

ddi_xetb(9F). ddLpatb<9F), ddi.regs_manJr*e<9F). aVfi.rega\nun.3etup(9F). ddij-ep_getb(9F). 
d<ti_device_a«_attr(9S) 
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Claims 



1 . A method for achieving portability of a device driver between at least two host computers for communicating with a 
device having first data access attributes, the driver having computer instructions for execution by a host computer 
having second data access attributes and a memory storing the computer instructions of the driver, the method 
comprising the steps of: 

allocating memory space in a device driver interface (DDI) environment for a handle; 

selecting, by the DDI environment, at least one of at least two DDI data access function implementations, 

wherein the selected implementation accounts for differences between the first and second data access 

attributes; 

storing, by the DDI environment information in the handle for accessing the selected DDI data access function 
implementation; and 

passing, by the DDI environment, a handle pointer to the driver for opaque access by the driver to the device 
through the DDI environment, the DDI environment using the information in the handle for invoking the selected 
DDI data access function implementation, the driver having no information about the second data access 
attributes. 

2. A method as recited in claim 1 , wherein the step of storing information in the handle comprises storing an address 
of the selected DDI data access function implementation in the handle. 

3. A method as recited in daim 2, wherein the handle has a host specific portion, and wherein the step of storing the 
address comprises storing the address in the host specific portion of the handle. 

4. A method as recited in claim 1 , wherein the handle has a bus specific portion, further comprising the step of storing 
data for identifying the device's bus parameters in the bus specific portion of the handle. 

5. The method as recited in claim 1 , further comprising the step of passing the handle pointer from the driver to a func- 
tion call in the DDI environment for indirectly calling the selected DDI data access function implementation. 

6. The method as recited in claim 1 , further comprising the step of passing the handle pointer from the driver to a func- 
tion call in the DDI environment for direct data access to the device with host hardware. 

7. The method as recited in claim 1, further comprising the step of passing, by the driver, the first data access 
attributes from the device driver to the DDI environment. 

8. The method as recited in claim 7, wherein the handle comprises a common portion for storing the first data access 
attributes. 

9. An apparatus for achieving portability of a device driver between at least two host computers for communicating 
with a device having first data access attributes, the driver having computer instructions for execution by a host 
computer having second data access attributes and a memory storing the computer instructions of the driver, the 
apparatus comprising: 

a device driver interface (DDI) environment; 

a setup mechanism in the DDI environment configured to allocate memory space in the DDI environment for a 
handle; 

a selector in the DDI environment configured to select at least one of at least two DDI data access function 
implementations, wherein the selected implementation accounts for differences between the first and second 
data access attributes; 

a storage medium in the DDI environment configured to store information into the handle for accessing the 
selected DDI data access function implementation; and 

a return function mechanism configured to have the DDI environment pass a handle pointer to the driver for 
opaque access by the driver to the device through the DDI environment, the DDI environment using the infor- 
mation in the handle for invoking the selected DDI data access function implementation, the driver having no 
information about the second data access attributes. 

10. An apparatus as recited in claim 9, wherein the information for accessing the selected DDI data access function 
implementation comprises an address of the selected DDI data access function implementation in the handle. 
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11. An apparatus as recited in claim 10, wherein the handle has a host specific portion, and wherein the storage 
medium is configured to store the address in the host specific portion of the handle. 

12. An apparatus as recited in claim 9, wherein the handle has a bus specific portion, further comprising a storage 
5 medium configured to store data for identifying the device's bus parameters in the bus specific portion of the han- 
dle. 

1 3. The apparatus as recited in claim 9, further comprising a function calling mechanism configured to pass the handle 
pointer from the driver to a function call in the DDI environment for indirectly calling the selected DDI data access 

io function implementation. 

1 4. The apparatus as recited in claim 9, further comprising a function calling mechanism configured to pass the handle 
pointer from the driver to a function call in the DDI environment for direct data access to the device with host hard- 
ware. 

15 

15. The apparatus as recited in claim 9, further comprising a function calling mechanism configured to pass from the 
driver to the DDI environment the first data access attributes. 

16. The apparatus as recited in claim 15, wherein the handle comprises a common portion for storing the first data 
20 access attributes. 

17. A computer program product comprising: 

a computer usable medium having computer readable code embodied therein for causing portability of a 
25 device driver between at least two host computers each having a memory, the computer program product com- 

prising: 

computer readable program code devices configured to cause a computer to effect allocating memory space 
in a device driver interface (DDI) environment for a handle; 

computer readable program code devices configured to cause a computer to effect selecting, by the DDI envi- 
30 ronment, at least one of at least two DDI data access function implementations, wherein the selected imple- 

mentation accounts for differences between the first and second data access attributes; 
computer readable program code devices configured to cause a computer to effect storing, by the DDI environ- 
ment information in the handle for accessing the selected DDI data access function implementation; and 
computer readable program code devices configured to cause a computer to effect passing, by the DDI envi- 
35 ronment, a handle pointer to the driver for opaque access by the driver to the device through the DDI environ- 

ment, the DDI environment using the information in the handle for invoking the selected DDI data access 
function implementation, the driver having no information about the second data access attributes. 

18. A computer program product as recited in claim 17, wherein the computer readable program code devices effecting 
40 storing information in the handle comprises computer readable program code devices to effect storing an address 

of the selected DDI data access function implementation in the handle. 

19. A computer program product as recited in claim 18, wherein the handle has a host specific portion, and wherein 
the computer readable program code devices effecting storing the address comprises computer readable program 

45 code devices to effect storing the address in the host specific portion of the handle. 

20. A computer program product as recited in claim 17, wherein the handle has a bus specific portion, further compris- 
ing computer readable program code devices to effect storing data for identifying the device's bus parameters in 
the bus specific portion of the handle. 

50 

21 . The computer program product as recited in claim 1 7, further comprising computer readable program code devices 
to effect passing the handle pointer from the driver to a function call in the DDI environment for indirectly calling the 
selected DDI data access function implementation. 

55 22. The computer program product as recited in claim 1 7, further comprising computer readable program code devices 
to effect passing the handle pointer from the driver to a function call in the DDI environment for direct data access 
to the device with host hardware. 

, 23. The computer program product as recited in claim 1 7, further comprising computer readable program code devices 
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to effect passing, by the driver, the first data access attributes from the device driver to the DDI environment. 
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